In recent years, a variety of communication services which utilize the Internet have come into use. One example of a communication protocol which is used for sending and receiving data over the Internet is TCP (Transmission Control Protocol). TCP is a connection-type communication protocol which enables highly reliable data communication to be carried out over the Internet. Under TCP, a data transmitting device (hereinafter, “server device”) and a data receiving device (hereinafter, “client device”) exchange connection data (hereinafter, “connection identifier”) prior to transmission of content data. The exchanged connection identifier is used to specify a communication path (hereinafter, “connection”) to thereby establish a connection for transmission of content data. Examples of connection identifiers include: a communication address assigned to a server device or a client device; data indicating a communication port (e.g. a communication port number) used by the devices for respectively transmitting and receiving data; or an initial value of a sequence number. Under TCP, a connection is established using a procedure referred to as a “3-way handshake”. A general description of this procedure follows.
FIG. 10 provides an overview of a 3-way handshake executed by a client device 20 and a server device 40. Each of the devices is capable of communicating under TCP. It is assumed for the purposes of this explanation that a user who wishes to obtain content data from server device 40 performs a predetermined operation such as inputting data (e.g., URL) representing a communication address of server device 40 and a communication protocol to be used for acquiring the desired content data. Client device 20 first transmits to server device 40 a SYN message 200, as shown in FIG. 10. SYN message 200 is used for requesting establishment of a connection when data is to be transmitted from server device 40 to client device 20 (hereinafter, “downlink connection”); and the message includes a connection identifier for the downlink connection.
Server device 40, upon receiving SYN message 200, allocates a computer resource (hereinafter, “resource”) for establishing a connection with the source of the SYN message 200, client device 20. Specifically, server device 40 writes, in a memory device such as RAM (Random Access Memory), data (e.g., a connection identifier of the downlink connection mentioned above) for identifying a correspondent device (i.e., client device 20). Server device 40 then transmits to client device 20 a SYN/ACK message 210 indicating receipt of SYN message 200, and also transmits a request for establishing a connection in the reverse direction (hereinafter, “uplink connection”). The uplink connection is used when data is transferred from client device 20 to server device 40; and the SYN/ACK message 210 includes a connection identifier for the uplink connection.
Client device 20, upon receiving SYN/ACK message 210, reads the connection identifier in the SYN/ACK message 210 and establishes a connection (i.e., an uplink connection) in accordance with the connection identifier. Client device 20 then transmits to server device 40 an acknowledgement message (hereinafter, “ACK”) 220 indicating receipt of the SYN/ACK message 210. Upon receiving ACK 220, server device 40 establishes the uplink connection, deletes data identifying the correspondent device from the memory device, and awaits receipt of a message from the correspondent device, such as a request for transmitting data.
It is to be noted that since resources of server device 40, such as a capacity of a memory device, are limited, a number of connection identifiers which can be stored in the memory device is also accordingly limited. Thus, a number of ACKs 220 from client devices 20 for which server device 40 can wait is limited to a number of connection identifiers which can be retained at the server. It is this limitation that makes a server vulnerable to abuse. Namely, a denial of service attack can be launched against the server by a malicious client device by sending from the device a large number of SYN messages 200 to the server for queuing, thereby exhausting the resources of the server. Such an attack is referred to as a “SYN Flood Attack.”
When a SNY Flood Attack is launched, a malicious client device which is the source of the attack continuously transmits a large number of SYN messages 200 to server device 40. When the server sends or attempts to send responsive SYN/ACK messages 210 no ACK 220 is forthcoming from the client device, and the server therefore retains for a set time period connection identifiers contained in the received SYN messages. When a number of connection identifiers queued at the server reaches an upper limit, the resources of the server device are exhausted. As a result, the server device is no longer able to accept connection requests from client devices; and communication services cannot be provided. Various methods have been proposed for dealing with SYN Flood Attacks. They include, J. Lemon, “Resisting SYN flood DoS attacks with a SYN cache”, Proceedings of the BSDCon 2002 Conference, 2002 where a technique called SYN Cookie is described. Referring to FIG. 11, a description of SYN Cookie will now be given.
FIG. 11 provides an overview of a connection opening procedure carried out according to SYN Cookie. When a server device 50 establishes a connection according to SYN Cookie when receiving a SYN message 200 from client device 50, it generates hash data by compressing the content of the received SYN message 200 according to a predetermined algorithm. Server device 50 then transmits to client device 20 a SYN/ACK message 210 after writing the generated hash data in the message 210. According to SYN Cookie, server device 50 does not write in its memory unit a connection identifier contained in SYN message 200 at the time of receiving the message 200. Instead, server device 50 reads a connection identifier from the hash data if the hash data is contained in an ACK 220 returned from client device 20, and then establishes a connection (i.e., downlink connection) based on the connection identifier. Thus, according to SYN Cookie, since server device 50 does not store a connection identifier contained in a SYN message 200, there is no danger of resources of server device 50 being exhausted even in a case that ACKs 220 are not returned from a client device(s). Accordingly, server device 50 is able to avoid a denial of service state from being created by a SYN Flood Attack.
However, given that TCP provides that a message be retransmitted if an ACK is not returned from a correspondent device within a predetermined time after transmission of a message, as shown in FIG. 11, server device 50 according to SYN Cookie must retransmit SYN/ACK message 210 in a case that ACK 220 is not received within a predetermined time after the transmission of SYN/ACK message 210. However, since server device 50 does not store a connection identifier contained in SYN message 200, it cannot retransmit SYN/ACK message 210 as it is unable to identify a destination of SYN/ACK message 210 for retransmission; this destination would conventionally be identified on the basis of a stored connection identifier.
As a consequence, a connection between server device 50 and client device 20 remains incomplete if ACK 220 is not transmitted to server device 50 from client device 20 in response to SYN/ACK message 210, or is transmitted but is lost in transmission and fails to reach server device 50. Specifically, while an uplink connection between server device 50 and client device 20 is established if client device 20 safely receives SYN/ACK message 210, a downlink connection is not established due to the loss of ACK 220. That is, an incomplete, half-open state of connection is created between server device 50 and client device 20. This half-open communication state once created will persist since a downlink connection will not be established if SYN/ACK message 210 cannot be retransmitted to thereby cause client device 20 to retransmit ACK 220. Thus, using SYN Cookie to deal with a SYN Flood Attack is liable to give rise to a problem that a connection between a server device and a client device remains incomplete.